Monster Media 1994 #2

home *** CD-ROM | disk | FTP | other *** search

/ Monster Media 1994 #2 / Monster Media No. 2 (Monster Media)(1994).ISO / utils1 / exc35a.zip / EXC.HST < prev next >

Wrap

Text File | 1994-07-07 | 20KB | 438 lines

REVISIONS FOR VERSION 1.1 OF EXC.EXE Many thanks to the few users who have reported problems and/or suggested enhancements. If you don't report them and I don't find them, they don't get fixed. 1. I apologize for the EXC.DOC file. In my rush to get it documented and uploaded, I neglected to spell check or proofread it. It was terrible. I hope it is much more readable now. 2. Leading and trailing TAB characters (hex 09) were not being removed from script lines, causing invalid command messages. 3. There appears to be a need in the user community to repeat commands, groups of commands and keys a known number of times to allow them to write smaller scripts. Added "ON n label". This is a powerfull loop control command similar to the logic used in FOR statements common in many programming languages. Added a repeat number that can be added to the end of a KEY command. The key that is specified will be repeated as many times as specified. For instance, "KEY <TAB> 5" stuffs five tabs into the keyboard buffer. 4. Fixed a problem where certain invalid key mnemonics were not generating error messages. 5. If you loop through SEARCH commands looking for multiple possible messages that could occur, each time the timer interrupt is invoked (18.2/sec) the entire screen is read, reformatted to remove attributes and searched for each SEARCH in the loop. WAITFOR and WAITSCR have built-in one second delays between screen reads to minimize this overhead. One solution is to stick a DELAY in the loop, but if you do this between each SEARCH, execution of the script will slow down dramatically. I added a READ command that will read the screen and do nothing else. I then added a LOOK command that searches the screen buffer that was last read by a READ, SEARCH, WAITFOR or WAITSCR command. It's just like the SEARCH command without reading the screen prior to the search. EXAMPLE 1: EXAMPLE 2: EXAMPLE 3: :Loop :Loop :Loop SEARCH "Continue?" READ SEARCH "Continue?" IFY Continue LOOK "Continue?" IFY Continue LOOK "ERROR:" IFY Continue LOOK "ERROR:" IFY Error LOOK "ERROR:" IFY Error GOTO Loop IFY Error DELAY 1 :Continue DELAY 1 GOTO Loop . GOTO Loop :Continue . :Continue . :Error . . . . :Error . :Error . . . . In the above examples, Example 1 shows how you would have intuitavely coded the script in version 1.0. Adding a DELAY 1 at the end of the loop would have helped performance, but two screen reads would be per- formed each second. Example two demonstrates how READ and LOOK could be used to make a very efficient loop. Example 3 shows that, since a READ followed by a LOOK is equal to a SEARCH, so the third example is the best because it takes two iterations of the interrupt to process each command in the script. The first iteration reads and formats the command and the second executes it. 6. Installed COMMAND.COM as the default program name on the command line. 7. Modified QUIT and end0of-script logic to issue EXIT if COMMAND.COM was invoked. REVISIONS FOR VERSION 1.2 OF EXC.EXE Many thanks to the few users who have reported problems and/or suggested enhancements. If you don't report them and I don't find them, they don't get fixed. 1. Timeout processing was malfunctioning for WAITSCR. Fixed. 2. READ and LOOK were mistakenly included in v1.1 documentation, but are not actually implemented until v1.2. 3. In 1.1 and older, the maximum screen size was 80x50. EXC returned an error if you were in a larger screen mode. Also I had to obtain a 8,000 byte buffer (character + attribute) to read the 80x50 screen regardless of the text mode you were using. I must preallocte the screen buffer because the spawned program may consume all remaining memory. I can't just use the current video settings since the spawned program may change the text mode. I have added a command "SCRMAX cols rows" that allows preallocation of buffers for large screen sizes. The default, if SCRMAX is not in the script, will be the rows and columns of the text mode in use when EXC is invoked. Please read the documentation under SCRMAX for full usage instructions and the implications and penalties involved in reserving large screen buffers. This prevents wasting memory in screen sizes smaller than 80x50 and allows EXC to fully function on screens larger than 80x50. Supported screen widths are from 40-200 columns. Supported screen heights are from 20-100 rows. 1. I no longer read the video attribute when I read the screen, thus cutting screen buffer requirements in half. 2. To minimize problems with spawned programs which may also be using timer interrupts, I have broken down the execution of many commands into parts executed in multiple timer interrupts. 3. For the same reason as for the previous changes, I have cut the time down for error beeps and for the delay the beeps. Errors, which emitted 4 beeps now only beep twice. 4. Timeouts, which emitted 3 beeps now emit no beep. If you need to know when a timeout occurred, place a beep in your script where needed. This is primarily because intentional timeouts could be quite common and don't require user attention. 5. Modified DELAY and TIMEOUT processing to compare against the system clock instead of using countdown timers via INT 1C. This gives more accurate timing since 1C may or may not be called 18.2 times per second, depending on how long the interrupt handler had it tied up. 6. I have added key combinations that will terminate (LEFT and RIGHT SHIFT keys)and pause/resume (SCROLL LOCK) the execution of scripts. Unlike pressing the PAUSE key, SCROLL LOCK pauses only script execution and not the spawned program. The PAUSE key will suspend both. 7. I have insterted code that detects pause state and suspends all delays until pause state is exited. For example, if you press the PAUSE key 5 seconds into a 10 second delay, when you press a key to resume processing, you will still have 5 seconds of delay before the next command is executed. No new commands will be initiated during pause state. 8. Fixed a problem that limited total memory allocations to 64k and sometimes caused system halt if more was requested for scripts, screen or spawned program. 9. Enhanced functionality and script debugging by adding the following 14 new commands: TICK CLEAR PAUSE TIME WINMAX WINCOLS WINROWS CURSOR SHOWAT SHOW SHOWWIN LOCATE HIDEWIN TYPFILE 10. Rearranged the documentation so that commands are listed alphabetically. Added more examples. Added more in-depth explanations of operational considerations that might effect EXC's performance or lack thereof. 11. Included the script that I use for testing EXC in the distribution files. This provides at least one example of every command EXC recognizes. 12. Allow entry of quotes within a string by substituting \q for ". Version 2.0a The programs in version 2.0a are identical to those in version 2.0, except for the registration remider screen. The reminder screen and documentation have been updated to include instructions on how to register EXC online via CompuServe's SWREG section. REVISIONS FOR VERSION 2.1 OF EXC.EXE 1. Recompiled EXC in 8086/8088 code so that it could be used on XT class machines. Performance impact on 286 and above processors is negligible. 2. Added a parameter to the QUIT instruction. Normally on exit, EXC returns the return code of the executed program. If a number (0-255) is specified with the QUIT command, that value is returned as the DOS ERRORLEVEL return code instead of what was passed from the spawned program. An example of why you would want to set a return code: I use EXC to control PROCOMM PLUS to execute a script that synchro- nizes my clock with the Naval Observatory. I need to know if it fails. I can detect the error with my EXC script, but when I exit PCPLUS, PCPLUS always returns a return code of 255. Using the QUIT nn format, I can set a return code of 1 on error and 0 when there is no error. 3. After a PRTSC key mnemonic was executed, the script processor failed to continue to the next line and terminated at that point. REVISIONS FOR VERSION 2.2 OF EXC.EXE 1. Added support for using environment variables in any command string parameter. 2. When you tried to pass a parameter to the spawned program that contained spaces and was enclosed in quotes, the parameter arrived to the spawned program broken down into multiple one-word parameters. While EXC was passing it as a single parameter, DOS was breaking it down. I had to make sure each parameter passed to the spawned program was enveloped in quotes in order to assure proper operation. 3. EXC could have been copying one or more input parameters to uninitialized string pointers. This means that the parameters could have been copied anywhere in memory. These storage violations could cause random errors varying in degree of nastiness and symptioms. These pointers now point to a fixed array of allocated memory. If you experienced random, strange occurances after using EXC, this could be the cause. It could also cause QEMM exception 13 errors. I examine my code very closely for these nastiest of bugs, but with the flexibilty of data types, pointers and arrays used in C++, it is nearly impossible to find them until a repeatable error can be found. If you experience unusual problems after using EXC v2.2, try your best to repeat them. If you can in any way recreate the problem or narrow down the activity that causes the problem, let me know. EXC is becoming a very stable product now, thanks to your help. In this type of program it is impossible to test every combination that users will use. REVISIONS FOR VERSION 2.3 OF EXC.EXE Version 2.2 attempted to properly pass quoted parameters by enclosing all parameters in quotes. While this worked fine on Borland C and C++ programs, if the spawned program was PASCAL or assembler, it received the parameter with the quotes. Since most programmers were not expecting quoted parameters, they had no code to handle them. Borland C always removed the quotes before a program could access the parameters. This means that EXC VERSION 2.2 DID NOT WORK WHEN MOST PASCAL AND ASSEMBLER PROGRAMS WERE INVOKED. I now check each parameter for a space, |, < or >. If it contains one of these, I assume the input string was quoted and pass it on with surrounding quotes. All other parameters are passed as-is. \" can no longer be used to imbed quotes in a parameter to be passed to a spawned program. \q must be used instead. REVISIONS FOR VERSION 2.4 OF EXC.EXE 1. Although EXC processed correctly, sometimes an erroneous warning message would appear at the end of the job stating that the script had failed to complete and claiming to have stopped at the last command in the script. The last command had, in fact, been executed. 2. Instead of assuming COMMAND.COM for the default when no spawned program is specified, I now use the program specified in the COMSPEC environment variable. If COMPSEC is not found in the environment, I then use COMMAND.COM. REVISIONS FOR VERSION 2.5 OF EXC.EXE 1. It appears that a few applications and at least one well known appli- cation development package actually write binary zeros to certain parts of screen memory. These appear as spaces on the screen but are actually read as binary zeros when EXC reads screen memory. When EXC is searching the video memory for a string, it uses a string search algorithm that is terminated at the first binary zero. This is because C++ uses binary zeros to terminate strings. The result is that certain string text would be displayed on the screen but would not be located by EXC because the search was terminated prematurely. EXC now replaces any binary zeros in the screen buffer text with spaces. This allows the search to perform as expected. 2. The ON function did not work properly when the counter was more than 9. This has been corrected. REVISIONS FOR VERSION 2.6 OF EXC.EXE The DELAY and TICK commands did not always work properly if the wait state was in effect at midnight when the system timer clock rolls over to zero. EXC has been modified to compensate for this possibility. Version 2.6a: We are moving. Updated registration screen and documentation to show new address. No functional changes. REVISIONS FOR VERSION 2.7 OF EXC.EXE 1. Prior versions of EXC did not work on a few common programs that had their own keyboard interrupt handler. EXC has been modified so that it works on more of these programs than it used to. Since custom interrupt handlers can do anything they want, I cannot guarantee oper- ation on all of these programs. Fortunately, there are not many of them. Microsoft's EDIT and QBASIC editor now work properly under EXC. 2. Changed the TESTEXC.SCR script and TESTEXC.BAT batch file to operate with the DOS EDIT command found in DOS 5 and up. 3. Fixed a problem where, under the right conditions, some letters could be lost or scrambled when long strings were stuffed in the buffer. This would especially be prevalent in slower CPUs. 4. When EXC tried to branch to an invalid label, the correct error message was generated, but the STOPPED AT: message displayed garbage. It now points to the offending command. REVISIONS FOR VERSION 2.8 OF EXC.EXE 1. Release 2.7 fixed a problem that did not allow it to run on a few programs with keyboard interrupt handlers. In correcting the problem, performance suffered when long TYPE or TYPFILE commands were issued. Release 2.8 restores the lost performance. 2. Added the SLOW, FAST, INT9 and NOINT9 commands for performance tuning and reliability. See EXC.DOC for an explanation of these commands. REVISIONS FOR VERSION 2.9 OF EXC.EXE 1. Some text editors do not automatically place a carriage return at the end of the last line of a text file. If a script was created which did not end the last line with a carriage return, the last line would be ignored by EXC. Fixed. 2. Abbreviated the registration reminder screen and reduced the delay from five seconds to three to comply with the requirements of the Association of Shareware Professionals (ASP). 3. Revised the documentation to meet submission requirements of the ASP. 4. Modified to use pre-compiled subfunctions from a library, rather than included source. This has no bearing on EXC's functionality. 5. Added information in the documentation for problems in using EXC with some remote control communications programs. Included suggestions for resolving the problems. REVISIONS FOR VERSION 3.0 OF EXC.EXE 1. A big reason for this release to be 3.0 is that I was running out of release numbers under 2.x. However, there is one major feature addition that, while not often used, is a major step forward is making EXC usable in almost any DOS application. This might justify the major version number jump. You can now enter three-key and four-key combinations using SHIFT, ALT and CTRL. This was no easy task since these keys do have keyboard scan codes and cannot be stuffed in the keyboard buffer. Please read the EXC.DOC file before using three- or four-key combinations. 2. Added a parameter to the SLOW command to let you vary the speed at which strings and files will be typed. 3. Some text editors do not automatically place a carriage return at the end of the last line of a text file. If a script was created which did not end the last line with a carriage return, the last line would be ignored by EXC. Fixed. 4. Abbreviated the registration reminder screen and reduced the delay from five seconds to three to comply with the requirements of the Association of Shareware Professionals (ASP). 5. Revised the documentation to meet submission requirements of the ASP. 6. Modified to use pre-compiled subfunctions from a library, rather than included source. This has no bearing on EXC's functionality. 7. Added information in the documentation for problems in using EXC with some remote control communications programs. Included suggestions for resolving the problems. VERSION 3.0a EXC v3.0a is functionally equivalent to v3.0. The documentation has been modified to include the new address and phone number of Parity Solutions. Version 3.1 modifications: 1. Prior versions had an undocumented quirk which prevented a second ON command from being processed while another was active. The quirk has been documented in EXC.DOC and the ONRESET command added to allow forced termination of a previous ON command. 2. A problem with environment variable substitution could sometimes cause unpredictable results. Corrected. 3. Added capability to set and change up to 16 user variables. As a side effect, subroutine execution is now possible. Version 3.2 modifications: 1. Created special handling routines to handle many previously undefined key combinations. 2. Created the EXCDEMO program for authors who wish to distribute automated demos of their software. Included information about EXCDEMO in the EXC.DOC file. Version 3.3 modifications: 1. Added the HLOCATE, VLOCATE, CURSX and CURSY commands to help automate menu navigation. 2. Borland's C and C++ compilers have always allowed a program name without an extension to be supplied to the spawn function. It would append .COM and .EXE in its attempts to load the file. Version 4.0's spawn does not provide this capability and I had to add the code to perform this function and provide compatability with previous versions of EXC. 3. The Borland C++ v4 includes 20k of exception handling code in every program whether C++ exception handling is used or not. This extra 20k is unnaceptable for EXC. With great difficulty, I found a way to exclude the code from my C++ program. If your diskette shipment was late, it was because I was struggling with this problem before shipping any version 3.3 copies. Version 3.4 modifications: 1. Added the FILE, GET, and REWIND commands to allow record level access to an external file. 2. Since Borland C++ v4.0 no longer supports code generation for 8088/8086 systems, EXC now requires at least a 286 processor.